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ABSTRACT 


This  thesis  places  the  Information  Resource  Management 
Architecture  of  the  U.S.  Coast  Guard  in  the  **contagious 
grow  th't_J^""st  age  of  Nolan's  model  of  organizational  computer 
growth.  Control  is  the  next  stage  predicted  by  the  model. 
The  financial  accounting  basis  of  EDP  chargeback  and  control 
systems  is  examined  as  a  precursor  to  developing  five 
management  control  requirements  of  the  IRM  architecture. 
These  include  (1)  aggregate  financial  accounting  for  infor¬ 
mation  services,  (2)  an  auditable  user  access/authorization 
scheme,  (3)  a  user -ori ented  chargeback  system,  (4)  pricing 
to  establish  an  information  marketplace,  and  (5)  an  informa¬ 
tion  decision  tool  to  assist  in  user  tradeoff  decisions 
between  information  services.  Finally,  an  integrated  system 
to  satisfy  these  requirements  at  the  Coast  Guard  District 
Office  level  of  the  IRM  architecture  is  described,  based  on 


a  Local  Area  Network  system. 
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A.  INFORMATION  SYSTEM  PROJECTS 

In  the  early  1970's,  the  U.S.  Coast  Guard  began  automa¬ 
ting  and  integrating  the  administrative  and  communications 
systems  which  constitute  its  servicewide  Information  System. 
A  number  of  major  Information  System  Projects  were 
identified,  each  specifying  a  single  functional  system, 
usually  vertically  integrated  from  the  data-entry  field  unit 
through  to  the  Program  Manager  level  at  Coast  Guard 
Headquarters.  Examples  include  the  Operational  Information 
System  project  (OPINS),  the  Personnel  Management  Information 
System  (PMIS),  the  Marine  Safety  Information  System  (MSIS), 
and  the  Standardized  Aids  to  Navigation  System  (SANDS). 
Other  projects  became  necessary  to  support  these  Information 
Systems;  the  Standard  Terminal  Project  competitively  bid  a 
requirements  contract  for  procurement  of  up  to  3900 
intelligent  communications  and  data  entry  terminals,  and  the 
Semi -Automated  Message  Processing  Project  (SAMPS)  began 
computerizing  manpower  intensive  relay  points  in  the  record 
communications  network. 

B.  THE  OFFICE  OF  T 

The  Paperwork  Reduction  Act  of  1980  mandated  a  central 
point  of  information  management  in  each  agency.  In  1981  , 
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responsibility  for  the  various  Information  Projects,  and 
for  Information  Resource  Management  Coast  Guard-wide  was 
vested  in  a  newly  formed  Office  of  Command,  Control  and 
Communications  (C^),  synthesized  from  the  former  Financial 
Information  Systems,  Electronic/Electrical  Engineering,  and 
Telecommunications  Management  Divisions  at  Coast  Guard 
Headquarters.  Its  staff  symbol,  ( Commandant )G-T,  became 
widespread  verbal  shorthand  and  the  "Office  of  T"  was  born. 

C.  THE  U.S.  COAST  GUARD  INFORMATION  RESOURCE  MANAGEMENT 

ARCHITECTURE 

An  overall  schema  was  needed,  to  guide  the  integration 
and  coordination  of  the  various  separate  information  systems 
and  the  supporting  projects  into  a  servicewide  Coast  Guard 
Information  System.  The  Office  of  T  developed  and  published 
the  Coast  Guard  Information  Resource  Management  Architecture 
illustrated  in  Figure  1.  The  two  primary  policy  documents 
supporting  and  implementing  this  architecture  are  the 
(DRAFT)  Command,  Control  and  Communications  (C^)  Plan  [Ref. 
1],  and  the  Command,  Control  and  Communications  (C^)  Support 
Program  Plan,  1982-1992,  [Ref.  2]. 

1 .  Overview  and  Critical  Success  Factors 

The  best  overview  and  explanation  of  the  Information 
Resource  Management  (IRM)  Architecture  is  in  the  C^  Plan 


itself : 


U.S.  Coast  Guard  information 
Resources  Management  Architecture 
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Figure  1.  U.S.  Coast  Guard  Information  Resources 
Management  Architecture 


"Information  Architecture  Plan. 

The  first  step  in  effective  Information  Resource 
Management  is  to  develop  the  Information  Architecture 
Plan.  This  is  similar  to  a  business  plan  in  a  commercial 
firm.  The  information  needs  and  activities  of  the  various 
parts  of  the  organization  (emphasis  added)  are  collected 
and  analyzed  to  determine  the  manner  in  which  data  must  be 
organized  to  support  them.  This  leads  to  development  of  a 
logical  model  which  describes  the  arrangement  and  activi¬ 
ties  of  the  organization.  This  logical  model  has  been 
found  to  be  quite  stable  unless  the  fundamental  character 
of  the  organization  is  altered  or  its  missions  change 
radically  in  a  short  time.  Because  the  logical  model  is 
stable,  evolutionary  changes  can  be  accommodated.."  [Ref. 
1 :  p.  32] . 

The  added  emphasis  underscores  the  fact  that  unless 
a  part  of  the  organization  articulates  an  information  need 
or  activity,  the  Plan  cannot  address  it.  Needs  of  the 
system  overall,  "global"  needs  (like  a  need  for  management 
control)  will  not  enter  the  Architecture  without  a  sponsor, 
since  they  are  not  the  assigned  task  of  any  specific 
organizational  element. 

The  Coast  Guard  has  identified  four  Critical  Success 
Factors  for  developing  the  Information  Resources  Management 
Architecture : 

1  .  Intelligent  Terminals-- to  provide  a  vehicle  for  local 
processing,  source  data  entry,  and  access  to  the  net¬ 
work  (  s ) , 

2.  Data  Base  Technology — to  control  the  data  resource, 

3.  The  Communications  Network--to  provide  connectivity, 
and 

4.  Integration--of  the  parts  into  a  whole. 

[Ref .  3:  p.  STSP3  ] 


The  emphasis  on  database  technology  was  not  in  ton 2 t.o 
allow  the  creation  of  many  parallel  vertical  information 
systems : 


"The  IRM  architecture  and  other  policies  of  the  (Office  of 
T)  program  discourages  the  proliferation  of  field-unit 
terminals  connected  independently  to  s ingl e- or  og  ram 
central  data  bases.  This  would  be  an  electronic  version  of 
our  present  uncoordinated,  overlapping,  manual  information 
system."  [Ref.  1:  pp.  4-7] 

The  databases  shown,  at  Headquarters,  in  the  District 
Offices,  and  at  major  shore  facilities,  are  to  be  shared, 
multi-purpose  databases. 

The  number  of  mini -computers  shown,  coupled  with  the 
identification  of  intelligent  terminals  as  a  Critical 
Success  Factor,  mean  that  this  is  a  'distributed'  system. 
Computing  power  is  placed  as  close  as  possible  to  the  people 
who  need  to  use  it.  This  contrasts  with  a  centralized  system 
where  all  computing  is  done  at  one  usually  large  central 
computer  and  user  terminals  are  capable  only  of  data  entry 
and  routine  inquiries. 

2 •  Classes  of  Information  Serviced 

The  C^  Support  Plan  addresses  the  three  classes  of 
information  which  the  IRM  Architecture  will  have  to  service: 
transactional,  hierarchical,  and  local.  Figure  2  illus¬ 
trates  the  flow  of  hierarchical  information: 

"This  figure  shows  hierarchical  information  flowing  from 
the  smallest  unit,  to  the  top  of  the  Coast  Guard,  and 
ultimately  beyond  to  both  Congressional  and  Executive 
recipients.  While  all  three  types  of  information  have 
gray  areas  of  overlap,  the  essential  features  of 
hierarchical  are  aggregation,  and  use  by  management  over 


time  periods  of  weeks  to  years.  These  two  features  mean 
that  the  timeliness  of  the  information  is  not  critical, 
and  the  precision  and  detail  of  the  aggregated  information 
decreases  as  the  hierarchical  level  increases.  Hierarchi¬ 
cal  information  supports  the  management  control  and 
strategic  control  functions  of  the  organization.  [Ref.  2: 
p.  4-2] 

Hierarchical  Information 


Higher  Gov't 


Tim*  Not  Critical 
Oats:  Complex  Stmctur* 

Aggregated  ft  Summarized 
Use:  Management  Allocation.  Planning,  Control 
Traditionally:  Paper  Systems 

Figure  2.  Flow  of  Hierarchical  Information 


Transactional  information  flow  is  shown  in  Figure  3  and 
defined  as  Hows: 

""  gure  illustrates  transactional  information, 
bas  ..  data  groupings  which  flow  intact  from  point-to- 
poi  the  organization  and  usually  cause  or  support 
rapid  activity.  In  contrast  to  hierarchical  information 
the  precision  of  transactional  information  is  constant  and 
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transactions  are  not  usually  aggregated.  Th - s  infornation 
type  is  often  found  in  our  present  record  *m unications 
and  feeds  the  operational  control  function^  operating  the 
organization  day-in  and  day-out).  A  "message  MILSTRIP"  is 
a  perfect  example.  Transaction  information  often  has  a 
complex  input  to  hierarchical  and  this  input  (and  often 
its  duplication)  is  a  significant  problem/cost  to  the 
Coast  Guard."  [Ref.  2:  p.  4-2] 

(The  message  MILSTRIP  mentioned  is  a  telexed  supply 
requisition.)  Local  information  is  defined  as  any  and  all 
information  that  an  individual  or  organizational  element 
chooses  to  use  and  keep  when  it  is  not  institutionally 
required  to  do  so. 

Transaction  Information 


Tlmr  Usually  Critical 
Data:  Simple  Structure 
Intact  End-t»End 
U»*  OPS  C2  ft  Direct  Support 
Traditional  CO  Record  Imaaaagal  Communications 


Figure  3.  Flow  of  Transactional  Information 


3 .  The  Role  of  the  District  Office 

Central  to  all  three  of  the  figures  depicting 
information  flow  in  the  Coast  Guard  has  been  the  Coast  Guard 
District  Office.  Situated  between  the  strategic  level  of 
Coast  Guard  Headquarters  and  the  operational  level  of  the 
field  units,  the  District  Headquarters  operates  at  the  level 
of  management  control.  Every  major  Headquarters  Office 
and/or  Program  Manager  connects  to  a  corresponding  District 
Division  or  Branch.  Districts  are  responsible  for  managing 
Coast  Guard  resources  within  a  given  geographic  area  (i.e. 
Fifth  District  =  Maryland,  Virginia,  N.  Carolina).  The 
District  Commander  (a  two-star  Admiral)  as  the  principal 
agent  and  representative  of  the  Commandant,  is  responsible 
for  the  administration  and  general  direction  of  district 
units  under  his  command.  Within  his  District,  he  is 
responsible  for  carrying  out  the  functions  and  duties  of  the 
Coast  Guard  and  for  assuring  that  these  duties  are  performed 
efficiently,  safely  and  economically.  Districts  produce  the 
majority  of  transactional  information.  [Ref.  2:  pp.  1-10] 
Table  I  shows  the  names  and  locations  of  the  twelve  District 
Offices . 

The  District  Commander's  responsibility  for  local 
control  of  Coast  Guard  resources  extends  to  information 
resources,  too.  In  1981,  three  officer  billets  (One  Comman- 
der(0-5),  one  Lieutenant (0- 3 )  and  one  Warrant  Officer(CWO- 
4))  wefe  added  to  the  staffs  of  each  of  the  twelve  District 


Offices  to  form  the  nucleus  of  an  IRM  staff.  Combined  with 


the  existing  telecommunications  organization,  they  are  meant 
to  evolve  into  the  providers /supervisors  of  all  the 
information  services  shown  in  the  "CG  District"  box  within 
Figure  1.  This  District  IRM  staff  will  operate  the  Local 
Area  Network  and  the  District  Mi ni -Compute r ,  maintain  the 
District  database  and  provide  the  Information  Center 
services  specified  in  the  IRM  Architecture. 


Table  I.  U.S.  Coast  Guard  District  Office  Locations 


District 


First  District 
Second  District 
Third  District 
Fifth  District 
Seventh  District 
Eighth  District 
Ninth  District 
Eleventh  District 
Twelfth  District 
Thirteenth  District 
Fourteenth  District 
Seventeenth  District 


District  Headquarters 
Location 

Boston,  MA 
St  Louis,  MO 
New  York,  NY 
Portsmouth,  VA 
Miami,  FL 
New  Orleans,  LA 
Cleveland,  OH 
Long  Beach,  CA 
San  Francisco, CA 
Seattle,  WA 
Honolulu,  HI 
Juneau,  AK 


D.  THE  DISTRICT  LOCAL  NETWORK 

While  the  IRM  Architecture  and  its  support  plans  provide 

for  and  define  a  local  network  capability  for  each  District, 

it  is  not  a  critical  nor  a  high-priority  project.  The  C3 

Plan  defines  the  Local  Network  as  follows: 

"Within  the  district  office  building  and  immediate 
surroundings,  the  local  net  provides  for  information 
distribution  through  interconnected  clusters  of  Standard 
Terminals  or  other  existing  office  information  systems. 
Primary  objectives  are  shared  electronic  files,  electronic 


mail,  word  processing  and  shared  information  processing. 

[ Ref .  1  :  pp.  1-10] 

The  implementing  Support  Plan  notes  that  the  multi-user 
capabilities  of  the  Standard  Terminal  resemble  network 
connectivity,  and  that  clusters  of  Standard  Terminals  could 
be  interconnected  in  a  'message  mode'.  However,  this  inter¬ 
connection  and  more  advanced  techniques  like  wideband 
channel  local  area  networks  "will  not  be  pursued  for  general 
Coast  Guard  use  through  the  mid-80's,  although  R&D  evalua¬ 
tion  would  certainly  be  in  order"  [Ref.  2:  pp.  4-10],  The 
reasons  are  given  in  a  section  titled  "Future  Technology 
Impact  on  the  Architecture": 

"A  number  of  promising  technologies .. .have  been  excluded 
from  this  version  of  the  support  plan.  The  basic  reason 
has  been  one  of  practical  choice;  the  limited  resources 
available  to  the  program  and  the  need  for  evolutionary 
growth  dictate  that  higher  risk  or  non-integrable  ventures 
be  excluded... 

Local  Networks 

Mixed  voice/data/video  has  potential  payoff,  but  lack 
of  control  of  most  telephone  installations  makes  this 
difficult  to  exploit.  Some  use  of  this  later  in  the 
decade  will  no  doubt  occur."  [Ref.  2:  pp.  4-20]. 

Each  District  is  responsible  for  the  design,  acquisition, 

operation  and  maintenance  of  information  (voice  and  data) 

networks  within  the  geographic  boundaries  of  the  district. 

[Ref.  2:  p.  8-2],  The  local  net  is  not  regarded  as  a  piece 

of  the  IRM  Architecture  with  systemwide  impact. 
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E.  SUMMARY 


We  have  given  a  brief  overview  of  the  Coast  Guard's 
Information  Resource  Management  Architecture,  and 
established  the  central  role  of  the  Coast  Guard  District 
Office  within  that  architecture.  The  present  status  of 
local  networks  for  the  district  offices  was  examined;  that 
"back  burner"  status  is  consistent  with  the  C^  Plan's 
perception  of  local  nets  as  non-vital  local  utilities. 

The  Coast  Guard  is  still  in  the  process  of  buying  the 
equipment  for  the  architecture,  and  at  a  rapid  rate.  That 
rate  of  growth  is  examined  in  the  next  chapter  as  an 
indicator  that  the  Coast  Guard  will  soon  need  to  impose 
management  controls  on  its  servicewide  information  system. 
Later  we  will  discuss  the  type  of  management  controls  best 
suited  to  an  i nf orm a t ion - pr oce s s i ng  system,  and  the 
advantages  of  prototyped  development  of  those  controls.  A 
standard  District  Office  Local  Area  Network,  coupled  with  an 
auditable  user  authentication  and  access  system,  will  be 
suggested  as  a  mechanism  crucial  to  adding  management 
controls  to  the  IRM  Architecture. 


II.  COMPUTER  GROWTH  IN  THE  COAST  GUARD 


A.  THE  NOLAN  MODEL 

One  widely-accepted  framework  for  understanding  and 
evaluating  data  processing  (DP)  within  organizations  is 
Nolan's  six-stage  model  for  the  introduction  and  growth  of 
the  data  processing  function  within  organizations  [Ref.  4: 
pp.  76-89].  Figure  4  illustrates  the  six  stages  and  their 
characteristics  within  each  of  four  "growth  processes".  The 
climbing  dotted  line  represents  the  level  of  expenditures  in 
the  total  DP  budget  for  the  organization. 

This  model  is  a  refinement  of  Nolan's  earlier  (1974) 
four-stage  model  based  on  the  S-shaped  curve  described  by 
most  developing  DP  budgets  [Ref.  5:  p.  77],  The  "transition 
point"  of  the  later  (1  976)  model,  shown  in  Figure  4  is  the 
point  at  which  a  second  S-shaped  curve  takes  off.  This 
occurs  when  the  introduction  of  database  technology  causes 
renewed  rapid  growth  of  the  DP  budget.  This  later  model 
assumes  that  initial  applications  do  not  employ  database 
technology,  and  part  of  the  increased  expense  after  the 
transition  point  is  for  retrofitting  that  technology.  This 
assumption  may  limit  the  expense  curve's  direct 
applicability  to  the  Coast  Guard  IRM  Architecture,  given  the 

Plan's  stated  emphasis  on  widespread  use  of  database 
technology  from  the  beginning  in  all  applications.  The 
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stages  and  general  characteristics  of  the  six-stage  model, 
however,  have  been  validated  against  experience  with  more 
than  forty  large  corporations  and  should  still  apply  to 
Coast  Guard  computerization  [Ref.  4:  p.  116]. 
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Figure  4.  The  Nolan  Model  of  Organizational  Computer  Growth 

The  process  for  placing  a  corporation's  data  processing 
within  a  particular  growth  stage  involves  two  levels  of 
benchmarks: 


"The  first  step  is  to  analyze  the  company's  DP  expenditure 
curve  by  observing  its  shape  and  comparing  its  annual 
growth  rate  with  the  company's  sales.  A  sustained  growth 
rate  greater  than  sales  indicates  either  a  stage  2  or  4 
environment.  If  data  base  technology  has  been  introduced 
and  from  15%  to  40%  of  the  company's  computer-based 
applications  are  operating  using  such  technology,  then  the 
company  is  most  likely  experiencing  stage  4."  [Ref.  4: 

p.121] 

The  second  step  involves  evaluating  the  company's 
application  portfolio  against  the  investment  benchmarks 
shown  in  Table  II.  "For  instance,  80%  support  of 
operational  systems,  20%  support  of  management  control 
systems,  and  just  a  faint  trace  of  support  for  strategic 
planning  systems  would  show  the  organization  to  be  at  stage 
3."  [Ref.  4:  p.  124]. 


TABLE  II.  Applications  Portfolio  Investment  Benchmarks 


Stage 

Strategic 

planning 

systems 

Management 

control 

systems 

Operati 

systems 

1 

0 

0 

1  00% 

2 

<  1  % 

1  5% 

85% 

3 

<1% 

20% 

80% 

4 

5% 

30% 

65% 

5 

10% 

35% 

55% 

6 

1  5% 

40% 

45% 

B.  BETWEEN  CONTAGION  AND  CONTROL 

Trying  to  place  the  present  growth  stage  of  the  Coast 
Guard  IRM  architecture  is  difficult,  because  there  are  no 
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accurate  total  IRM  budgets  prior  to  the  establishment  of  tne 
Office  of  C^.  Many  of  the  operational  costs  of  the  Coast 
Guard-owned  record  telecommunication  system  (for  example, 
salaries)  are  still  disguised  as  overhead  expenses.  Many 
powerful  computers  (up  to  and  including  mini -computers )  have 
been  bought  for  word  processing,  and  don't  show  up  in  the 
budgets  of  the  comptroller-based  DP  departments. 

A  rough  approximation  can  be  made  by  simply  counting  all 
computers,  and  assuming  that  in  the  early  stages  of  growth 
expenses  are  linearly  related  to  the  number  of  available 
processing  units.  The  graph  in  Figure  5  shows  the  growth  in 
Coast  Guard  ADP  equipment  during  the  last  six  years,  based 
on  the  Coast  Guard  ADP  Equipment  Inventory.  This  inventory, 
which  GSA  (the  General  Services  Administration)  requires 
every  agency  to  maintain,  represents  a  current  census  of  any 
and  all  equipment  including  word  processors,  which  performs 
or  supports  directly  Automated  Data  Processing.  The  second 
curve  in  the  figure  shows  only  those  units  reported  as 
containing  a  Central  Processing  Unit,  i.e.  a  microprocessor; 
these  are  the  actual  'computers'  in  the  Coast  Guard 
inventory,  and  they  show  the  same  rate  of  growth  as  the 
total  hardware  curve.  Only  40%  of  the  Districts  had 
completed  reporting  their  FY  83  figures  at  the  time  these 
statistics  were  compiled,  but  the  figures  as  shown  are 
characteristic  of  the  Coast  Guard  in  general.  [Ref.  6]  The 
fallof.f  shown  in  the  first  curve  may  be  a  result  of 


incomplete  reporting  rather  than  the  end  of  a  hardware 
growth  trend. 


USCG  ADP  EQUIPMENT  GROWTH 


Figure  5.  Coast  Guard  ADP  Equipment  Growth 

Comparing  Figure  5  with  Nolan's  DP  expense  curve  in 
Figure  4  places  Coast  Guard  computer  growth  in  Stage  2,  the 
rapid  expansion  phase  labelled  'contagion'.  This  assumes 
that  the  Coast  Guard's  total  computer  expenditures  shows  the 
same  rapid  growth  illustrated  for  both  total  equipment  and 
for  CPU-equipped  units.  Since  software  is  not  reported  in 
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the  ADP  Equipment  inventory,  the  actual  budget  probably 
shows  a  higher  growth  rate  than  illustrated. 

The  second  step  in  the  placement  method  is  a  look  at  the 
organization's  applications  portfolio.  Table  III  is  a 
listing  of  Major  Information  Projects  of  the  Office  of 
Command,  Control  and  Communications,  taken  from  the  C3 
Support  Program  Plan  [Ref.  2:  p.  10-1].  Each  project  has 
been  categorized  by  the  organizational  level  it  primarily 
affects.  Eleven  of  these  fourteen  initial  computer  projects 
benefit  or  improve  operations  directly.  Three  of  the 
fourteen  improve  or  support  management  control.  According  to 
Nolan's  investment  benchmarks  in  Table  II,  these  figures 
place  the  applications  portfolio  in  stage  3,  the  control 
stage.  The  current  state  of  the  Coast  Guard  IRM 
architecture  is  therefore  between  contagion  and  control. 

The  rapid  growth  in  stage  2  starts  with  the  spectacular 
successes  of  the  initial  computerization  efforts  during 
stage  1.  The  excess  computer  capacity  usually  acquired 
during  the  first  phase,  coupled  with  the  lure  of  broader  and 
more  advanced  applications,  triggers  a  period  of  rapid 
expansion.  Stage  2  represents  a  steady  and  steep  rise  in 
expenditures  for  hardware,  software  and  personnel.  It  is  a 
period  of  contagious,  unplanned  growth  characterized  by 
growing  responsibilities  for  the  EDP  director,  a  loose 
(usually  decentralized)  organization  of  the  EDP  facility, 


and  few  explicit  means  of  setting  project  priorities  or 
crystallizing  plans. 


TABLE  III.  List  of  Major  Office  of  IRM  Projects 


MAJOR  PROJECT 

CATEGORY 

Marine  Safety  Information  System 

Operational 

Joint  Uniform  Military  Pay  System 

Operational 

Telecommunications  Study  -  Combine 
Computer  and  Record  Comms 

Operational 

Office  Automation 

Operational 

Command  Centers 

Operational 

District  Minicomputers 

Operational 

Shipboard  Assisted  Maintenance 
Planning  (SCAMP) 

Operational 

Yard/Supply  Center  Inventory  Control 
Point  Acquisition 

Operational 

G-T  Office  Budget  System 

Management  Control 

Coast  Guard  Standard  Accounting 
System 

Operational 

User  Responsibility ( Chargeback ) 

Management  Control 

Data  Management 

Management  Control 

Cobol  Conversion 

Operational 

Operations  Computer  Center 

Operational 

This  stage  often  ends  in  crisis  when  top  management 
becomes  aware  of  the  explosive  growth  of  the  activity  and 
its  budget,  and  decides  to  rationalize  and  coordinate  the 
entire  organization's  ED P  effort.  The  dynamic  force  of 
expansion  makes  this  a  fairly  difficult  thing  to  do, 


however,  and  the  growth  seems  to  be  continuing  unabated.  Top 
management  frequently  concludes  that  the  only  way  to  get 
control  of  the  resource  is  through  drastic  measures,  even  if 
this  means  replacing  many  systems  analysts  and  other 
valuable  technical  people  who  will  choose  to  leave  rather 
than  work  under  the  stringent  controls  that  are  imposed 
during  the  stage.  Firing  the  old  EDP  manager  is  by  no  means 
an  unusual  step. 

Often  what  was  a  decentralized  function  and  facility  is 
rather  suddenly  centralized  for  better  control.  Often 


informal  planning  suddenly  gives  way  to  formal  planning, 


perhaps  arbitrarily.  This  stage  frequently  includes  the 
first  formalization  of  management  reporting  systems  for 
computer  operation,  a  new  chargeback  system,  and  the 
establishment  of  elaborate  and  cumbrous  quality-control 
measures.  In  short,  action  taken  to  deal  with  the  crisis 
often  goes  beyond  what  is  needed,  and  the  pendulum  may  swing 
too  far. 

Based  on  his  studies  of  corporations  weathering  these 
computer  transition  stages,  Nolan  indicates  that  for  the 
most  part,  the  problems  that  arise  toward  the  end  of  Stage  2 


can  be  greatly  alleviated  by  introducing  right  at  the  start 


of  Stage  2  the  techniques  that  companies  ordinarily  use  in 


Stage  3."  [Ref.  5:  pp.  79-83  ] 


These  Stage  3  controls  are  shown  in  Table  IV  as  they 


were  presented  in  the  earlier  four-stage  model. 
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Table  IV.  Management  Techniques  Customarily  Applied  in  Each  of  the  Four  Stages 
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significant  in  this  figure  are  the  Stage  4  controls, 
specifically  the  data  base  policies  and  standards  and  the 
focus  on  computer  services  pricing  for  effective  use.  Later 
we  will  see  that  these  Stage  4  controls  are  the  type  which 
the  Plan  would  like  to  implement  directly.  For  now  the 
major  points  are  that  the  architecture  is  approaching  the 
control  stage,  and  the  early  introduction  of  controls  can 
greatly  ease  the  crisis  nature  of  the  transition  to  Stage  3. 

In  the  next  chapter,  we  will  examine  the  concept  of 
control  generally,  and  the  types  of  controls  available  for 
information  systems.  Some  specific  recommendations  will  be 
made  for  management  controls  consistent  with  the  Coast  Guard 


IRM  Architecture. 


III.  MANAGEMENT  CONTROL  OF  COMPUTERS 


A.  CONTROL  IN  GENERAL 

Management  control  is  a  cycle  that  includes  the  three 
stages  of  goal  setting,  performance  evaluation,  and  feed¬ 
back.  These  three  stages  of  control  are  illustrated  in 
Figure  6.  (1.)  Goal  setting  involves  planning,  and 

establishing  the  goals  required  for  desired  performance 
levels.  Measuring  and  monitoring  functions  record  actual 
performance.  (2.)  Performance  evaluation  compares 
performance  reports  with  goals.  (3.)  Feedback  information  is 
designed  to  make  corrections  in  either  goals  or  work 
activities  to  bring  them  into  alignment.  [Ref.  7:  p.  310] 


Performance  Reports 


Measuring  and 

Monitoring 


Figure  6.  Management  Control  Stages 
This  cycle  forms  the  heart  of  management  control  systems  in 
most  businesses,  with  the  department  or  division  budget 


quantifying  most  of  the  goals,  and  the  quarterly  financial 
statement  providing  the  performance  information  to  be 
evaluated  against  the  budget's  projections. 

B.  CONTROL  AND  CHARGEBACK  UNDER  CENTRALIZED  EDP 

Although  the  expense  and  the  technical  complexity  of 
computers  has  sometimes  obscured  the  point,  this  general 
model  of  management  control  can  be  applied  to  control  an 
Electronic  Data  Processing  department  as  directly  and  as 
well  as  any  other  department.  Top  management  has  two  main 
concerns  in  controlling  the  EDP  department: 

1.  Are  we  spending  too  much,  or  too  little,  or  just 
enough  on  EDP? 

2.  Is  the  money  we  have  allocated  to  the  department  being 
properly  spent? 

To  answer  these  questions,  and  control  EDP,  top  manage¬ 
ment  needs  two  key  structures.  The  first  is  a  financial 
reporting  system  that  allows  it  to  do  the  following  things: 

1.  Review  the  department's  performance  on  a  periodic 
basis . 

2.  Compare  the  department's  development  against  the 
formal  plans  for  it. 

3.  Check  the  functioning  of  the  department's  project 
control  systems. 

The  second  is  a  structure  that  links  the  responsibility 
for  various  departmental  decisions  to  the  operations  of  the 
users--ordinarily  other  company  departments.  Generally,  this 


structure  is  a  procedure  to  account  fcr  EDP  expenses,  either 
on  a  charge-out  or  an  overhead  basis.  [Ref.  8:  pp.  70,  83  ] 


As  in  other  business  activities,  the  key  performance 
reporting  information  is  financial;  for  EDP  it  is  used  to 
track  both  the  department's  performance  against  its  own 
goals  (department  budget  and  project  control  system),  and 
the  degree  and  mix  of  its  support  to  the  other  departments 
(chargeback  system).  Two  weak  spots  in  financial  control 
systems  for  EDP  departments  have  been  project  control  for 
software  development  and  user  chargeback  systems  based  on 
computer  resources  and  terminology.  Developments  in  software 
cost  estimation,  like  Boehm's  COCOMO  (Cost  Control  Model), 
and  techniques  like  structured  programming  and  programmer 
teams  have  greatly  reduced  the  difficulty  of  estimating  and 
controlling  software  development  projects.  Computer-oriented 
chargeback  systems  which  give  users  detailed  reports  of  the 
CPU-seconds,  main  and  secondary  memory  units  used,  etc.,  are 
gradually  being  displaced  by  user-oriented  systems  as 
computer  services  become  crucial  to  the  "bottom  line"  of 
most  operating  divisions.  The  reasons  for  these  new  systems 
will  be  discussed  later. 

The  financial  basis  of  management  control  of  EDP 
departments  has  two  important  implications: 

1.  As  a  general  rule  management  control  systems  for  data 
processing  cannot  be  significantly  more  advanced  than 
the  management  control  systems  used  for  the  company  as 
a  whole.  Since  accounting  systems  provide  the 
foundation  for  management  control,  management  control 
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can  only  reflect  the  quality  of  the  accounting 
system."  [Ref.  9:  pp.  311,  315] 

2.  The  development  of  data  processing  accounting  systems 
is  initially  an  accounting  problem  rather  than  a  data 
processing  problem  because  basic  accounting  concepts 
are  most  important.  Unfortunately,  this  need  for 
accounting  skills  is  not  recognized  from  the  start. 
Usually,  technical  personnel  play  the  dominant  role  if' 
designing  the  initial  DP  accounting  systems.  Rather 
quickly,  however,  it  becomes  apparent  that  the  real 
problems  are  financial  accounting  problems  concerning 
responsibility  centers,  costing,  and  allocating  costs 
to  responsibility  centers.  Accounting  personnel  are 
then  brought  into  the  project. 

These  fundamental  problems  seriously  hinder  the 

effective  design,  implementation  and  administration  of 

computer  use  chargeback  systems.  Simply  stated,  you  cannot 

build  a  sophisticated  control  system  on  a  sandy  foundation 

of  weak  accounting  systems.  [Ref.  9:  p.  315] 

1 .  Evolution  of  Chargeback  Systems 

Computer  chargeback  systems  were  originally 

accounting  devices  to  allocate  the  costs  of  a  very  large 

capital  investment  among  the  departments  that  used  it.  When 

most  of  the  processing  was  large  batch  jobs,  a  relatively 

simple  system  could  price  batch  jobs  according  their  use  of 

computer  resources,  as  reflected  in  reports  from  system 

monitor  programs. 

Differential  pricing  began  as  an  efficiency  measure, 
to  boost  use  and  distribute  the  workload  on  the  computer 
more  evenly  by  charging  less  for  jobs  run  during  the  evening 
and  night  shifts.  Once  the  computer  was  fully  scheduled 
(and  more)  it  became  a  scarce  resource;  prices  were  further 


differentiated,  and  coupled  with  a  priority  system  for  the 
jobs  themselves,  to  control  and  monitor  the  competition  for 
the  now-scarce  computing  time. 


An  important  transition  was  made  as  the 
organization's  goals  changed  from  efficient  (full  use)  to 
effective  (most  necessary  jobs)  use  of  the  computer  system. 
The  management  control  purpose  of  the  chargeback  system  was 
expanded  to  include  shaping  the  behavior  of  users. 
Information  not  necessary  to  proper  computer  operation,  i.e. 
job  class  and  priority,  was  added  to  jobs  and  the  operations 
monitoring  programs  were  changed  to  record  it.  The  range  of 
choices  available  to  the  user  department  grew,  but  the  costs 
of  those  choices  were  determined  by  the  EDP  department,  and 
still  largely  based  on  recovering  the  actual  costs  of 
equipment  and  operations. 

A  priority  system  and  a  single  scarce  resource 
implies  that  some  jobs  never  get  scheduled.  An  alternative 
to  the  central  EDP  department  came  about  as  decreasing 
equipment  costs  allowed  time-sharing  and  computer  service 
bureaus  to  develop,  and  it  became  theoretically  possible  to 
get  all  computer  projects  accomplished  without  a  major 
capital  investment  decision.  Rather  than  competing  for  use 
of  the  single  company  computer,  projects  could  be  subjected 
to  the  same  cost/benefit  analysis  used  for  other  business 
projects  in  the  firm.  For  the  first  time,  make-or-buy 
analysis  (whether  to  do  a  job  yourself  or  buy  it  from 
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someone  else)  could  be  applied  also.  This  open  market  of 
competition  to  the  central  EDP  facility  radically  changed 
the  management  control  uses  of  the  chargeback  system  again. 
An  open  market  fosters  competition  through  price,  and  allows 
the  chargeback  prices  to  be  used  to  judge  how  ef  f i ci en tl y 
the  EDP  department  delivers  computer  services.  The 
responsibility  for  e  f f  ec  ti ve  use  of  computer  services  was 
almost  totally  transferred  to  the  user  departments,  as  the 
organization's  experts  on  the  business  benefits  of  a 
particular  application.  Currently  organizations  require  the 
chargeback  system  to  isolate  as  completely  and  clearly  as 
possible,  the  actual  costs  of  the  specific  application.  The 
prices  must  be  refined  to  eliminate  the  variances  due  to  the 
operation  of  the  computer  department  from  the  actual 
consequences  of  the  "consumer's"  use.  This  provides  to  the 
user  the  best  cost  information  with  which  to  make  a  sound 
cost/benefit  decision  for  the  company.  Chargeback  is  also 
used  to  evaluate  the  user  for  efficiency  in  the  use  of 
computer  resources  in  accomplishing  his  or  her  business 
mission. 

Both  the  financial  accounting  and  the  computer- 
resource  accounting  abilities  of  the  organization  have  had 
to  mature  to  accomplish  the  expanding  management  control 
purposes  of  chargeback  in  an  increasingly  complex 
environment.  As  the  responsibility  for  effective  and 
efficient  us e  of  computing  resources  shifts  to  the  user 


departments,  they  have  demanded  that  charges  be  expressed  in 
units  they  can  understand  and  effect.  Applying  industrial 
accounting  techniques  allows  the  allocation  of  the  resource 
costs  per  job  (CPU-seconds ,  tape  and  disk,  drive  hours,  main 
and  secondary  memory)  to  be  priced  out  as  standard  costs  per 
work  unit  (cost  per  check,  per  invoice,  per  personnel  record 
update).  These  standard  costs  can  be  accumulated  by  section 
or  office  within  a  department  to  support  a  finer  degree  of 
control . 

The  implementation  of  management  control  through 
chargeback  is  a  dynamic  process.  Studies  of  the  process  have 
developed  four  criteria  for  judging  chargeback  systems: 

1 .  Understandability : 

To  what  extent  can  the  manager  associate  charge-out 
costs  to  the  activities  necessary  to  carry  out  his  or 
her  tasks? 

2.  Controllability: 

To  what  extent  are  the  charges  under  the  control  of 
the  user? 

3.  Accountability: 

Are  costs  and  utilization  of  computer-based  systems 
included  in  the  performance  evaluation  of  the  user? 

4.  Cost/benefit  incidence: 

Does  the  user  responsible  for  task  accomplishment  also 
receive  the  chargeout  bill?  [Ref.  9:  p.  317] 

In  addition  to  evaluation  criteria,  these  studies 
have  produced  several  vital  general  observations.  One 
mistake  frequently  observed  in  designing  an  effective  system 
is  to  impose  sophisticated  controls  upon  organizational 
units  that  are  not  "ready".  The  organization  unit  is  not 


L. 


4 


ready  if  controls  hinder  its  operation  or  if  personnel 
cannot  clearly  see  the  relevance  of  the  controls  to  their 
problems.  [Ref.  9:  p.  311  ] 

Chargeback  systems  also  evolve.  They  initially  are 
directed  at  high-level  managers.  Summary  data  processing 
bills  are  sent  to  divisional  controllers  without  much 
information  on  the  charges  being  conveyed  to  end  users.  With 
maturity,  the  charge-out  systems  become  more  sophisticated 
and  permit  detailed  bills  to  be  sent  directly  to  low-level 
users.  It  is  important  that  a  chargeback  system  does  evolve 
through  successive  phases  so  that  users  and  DP  managers  can 
learn  how  to  interpret  and  use  the  information.  It  is 
especially  important  that  the  means  for  accountability  be 
coordinated  with  the  expectations  for  accountability.  Users 


resent  charges  for  systems  they  cannot  affect. 

Management's  objective  is  to  develop  a  strategy  that 
will  increase  the  maturity  (and  effectiveness)  of  the 


charge-out  system  at  an  appropriate  pace  for  the  major  user 
groups.  It  is  likely  that  several  charge-out  strategies  may 
be  required  for  the  different  user  groups.  [Ref.  9:  p.  318] 


2.  Summary 
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In  the  process  of  developing  management  controls  for 

the  Coast  Guard  IRM  architecture,  the  lessons  we  can 

transfer  from  the  experience  of  centralized  EDP  include: 

1.  Management  controls  for  EDP  are  financial  in  nature 
and  thus  comparable  to  the  controls  on  other 
departments. 
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2.  They  have  a  stronger  base  in  good  accounting  than  in 
technology.  They  can  therefore  be  no  more  complex  than 
the  accounting  and  management  control  systems  of  the 
rest  of  the  organization. 

3.  A  chargeback  system  is  essential  to  management  control 
of  EDP  departments,  and  eventually,  EDP  users. 

4.  Chargeback  schemes  grow  and  mature.  Management  must 
develop  a  strategy  to  manage  this  process  at  an  rate 
appropriate  to  the  major  user  groups,  and  to  changing 
management  control  needs. 

An  important  although  not  obvious  point  is  that  the 
competition  for  computer  services  described  here  takes  place 
in  essentially  a  single  arena.  The  goods  and  services 
(reports,  database  queries,  CPU  cycles)  are  almost  perfectly 
interchangeable,  between  the  daytime  on-line  version  of  the 
payroll  and  the  late  shift  batch  run  of  the  same  program, 
even  between  the  in-house  product  and  the  service  bureau 
version  of  the  same  printout.  Competition  by  price  is  a 
logical  basis  of  comparison  of  substitutable  goods  in  the 
same  open  market,  whether  in  keeping  the  EDP  department 
'honest',  or  in  the  user's  trade-off  between  alternate  ways 
of  implementing  a  given  project.  As  a  management  control 
technique,  it  assumes  that  everyone  knows  all  the  prices 
(perfect  knowledge)  and  knows  the  substitutability  of 
various  goods,  so  changing  the  relative  pricing  should 
logically  effect  behavior. 

C.  EXPANDING  EDP  TO  IRM  AND  REFINING  CHARGEBACK 


Information  resource  management  obviously  entails  more 
than  cpntrolling  a  centralized  data  processing  center.  The 


Coast  Guard  has  defined  it  to  include  all  information 
processing:  transactional  and  operational  information, 
office  automation  as  well  as  data  processing  and  voice  and 
data  telecommunications.  This  expansion  means  it  includes 
what  Strassman  defines  as  a  second  major  sector  of 
information  processing,  "administrative  processing",  which 
he  says  is  largely  ignored  by  i n f orm a ti on -proce  ss  ing 
executives : 

"While  it  accounts  for  the  largest  and  most  frequently 
used  set  of  tools  and  facilities  for  handling  information 
transactions,  it  is  rarely  aggregated  under  a  single 
expense  heading.  It  includes  everything  from  typewriters, 
word  processors  and  dictating  equipment  to  telephone  and 
Telex  networks,  recording  devices,  copiers  and  duplica¬ 
tors,  facsimile  transmission  devices,  microfilm  equipment, 
and  even  such  relatively  mundane  necessities  as  office 
supplies,  mail,  and  simple  filing  systems.  These  adminis¬ 
trative  tools  are  quite  diverse  and  often  isolated  from 
one  another,  so  that  the  expense  involved  in  their  use 
tends  to  become  highly  diffused.  Historically,  little 
trade-off  has  been  possible  among  such  individual  office 
"technologies".  [Ref.  9:  p.  295] 

No  organizational  unit  is  responsible  for  integrating 
these  noncomputer  aspects  of  information  handling,  but  the 
fastest  expense  growth  in  the  office  environment  is 
occurring  here.  If  an  organization  intends  to  control  rising 
expenses  for  'white-collar  automation',  information  systems 
management  must  expand  to  include  careful  expense  accounting 
for  these  diverse  office  technologies.  This  control  must 
also  be  in  some  flexible  automated  form,  since  the  future 
volume  of  information  transactions  is  uncertain,  as  are  the 
relative  importance  of  various  cost  elements,  rapid  changes 
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in  technology,  and  shifting  attitudes  toward  office 
automation  by  labor  and  government.  [Ref.  9:  p.  296] 

In  addition  to  the  increased  size  of  the  total 
information  system,  and  a  greatly  increased  number  of 
transactions,  we  are  annexing  an  area  where  the  costs  are  so 
spread  out  as  to  be  hard  to  accumulate.  The  management 
control  job  will  be  further  complicated  by  the  lack  of 
direct  tradeoffs  between  the  products  of  some  of  the 
subsystems  in  the  architecture.  For  a  price-based  control 
system  to  work,  some  indirect  measure  of  substitutability 
among  the  systems  will  have  to  be  developed.  Considering  the 
massive  volume  of  transactions,  the  entire  control  system 
must  be  eventually  completely  automated.  It  is  more 
appropriate  to  call  it  an  'information  pricing  system' 
rather  than  'chargeback'.  A  good  encapsulation  of  the 
ultimate  goals  of  such  a  control  system  is  Strassman's  list 
of  the  objectives  for  a  top  information  executive  in  today's 
business  environment: 

*  Ensuring  the  integration  of  data  processing,  adminis¬ 
trative  processing,  and  office  labor  productivity 
programs . 

*  Instituting  accounting,  cos t- cont ro  1 ,  and  budgeting 
innovations  that  will  subject  all  information  systems 
overhead  activities  to  the  disciplines  traditionally 
applied  to  direct  labor. 

*  Subjecting  office  labor  automation  programs  to 
analyses  comparable  to  those  applied  to  all  other 
forms  of  capital  investment. 

*  Conceiving  organizational  designs  that  will  permit 
information  to  be  handled  as  a  readily  accessible  and 
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easily  priced  commodity  rather  than  as  a  bureaucratic 
possession . 

*  Creating  within  the  organization  an  internal  market 
for  alternative  information  systems  products,  so  that 
trade-off  decisions,  even  technologically  complex 
ones,  can  be  decentralized  into  the  hands  of  local 
user  management. 

*  Fostering  a  technique  of  pricing  that  will  allow 
decisions  on  introducing  new  technology,  or  abandoning 
obsolete  technology,  to  be  made  on  a  decentralized 
basis . 

*  Installing  and  monitoring  measurement  methods  that 
will  protect  improvements  in  productivity  achieved  by 
automation  programs. 

These  are  the  ultimate,  not  the  immediate,  goals  of  any- 
proposed  management  control  system  for  a  complete  informa¬ 
tion  system.  By  examining  the  purposes  and  evolution  of  EDP 
chargeback,  and  projecting  the  requirements  for  information 
systems  control  for  the  future,  we  have  set  the  stage  for 
considering  specific  recommendations  for  management  control 
requirements  of  the  Coast  Guard  Information  Resource 
Management  Architecture. 


IV.  CONTROL  REQUIREMENTS  OF  THE  ARCHITECTURE 

A.  SUGGESTED  MANAGEMENT  CONTROL  REQUIREMENTS  FOR  THE  COAST 

GUARD  INFORMATION  RESOURCE  MANAGEMENT  ARCHITECTURE 

To  pave  the  way  for  a  smooth  transition  to  the  control 
stage  of  computer  growth,  the  Coast  Guard  should  soon 
develop  the  information  or  systems  necessary  to  meet  the 
following  five  requirements: 

1  .  Aggregate  financial  information 

2.  Auditable  identification  of  users 

3.  Meaningful  chargeback  system(s) 

4.  An  'information  marketplace' 

5.  An  information  decision-making  tool 

Each  of  these  will  be  explained  in  detail  below.  These 
suggestions  assume  that  major  hardware  subsystems  (i.e. 
mainframe  or  minicomputers,  communications  network 
interfaces)  will  have  resource-accounting  monitor  programs 
installed . 

1 •  Aggregate  Financial  Information 

Since  the  primary  support  of  budget-based  management 
control  systems  is  good  accounting,  the  Coast  Guard 
accounting  system  should  be  modified  to  allow  for 
information  costs  to  be  aggregated,  both  by  organizational 
unit,  (i.e.  a  Division  or  a  Section  of  a  District  Office) 
and  by  a  project  identifier  (Project  D 1 7-21 ,  Develop 
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Operations  Database).  The  current  joint  project  of  the 
Office  of  and  the  Office  of  the  Comptroller  to  develop 
and  automate  a  Coast  Guard  Standard  Accounting  System  should 
address  whether  a  separate  Operating  Guide  (OG)  or  a  Subhead 
is  needed  to  identify  information  funds,  or  whether  an 
Object  Code  identifier  holds  enough  information  and 
flexibility  for  complex  financial  reporting.  A  unique 
identification  of  the  funds  as  information  funding,  along 
with  a  system  or  project  identifier,  and  a  capability  to 
retrieve  by  organizational  subunit  will  support  the  reports 
necessary  to  monitor  and  control  both  the  IRM  function  and 
the  end  users.  An  identifying  field  of  this  sort  would 
support  "information  budgets"  easily  when  cost  control 
becomes  necessary.  It  also  would  function  partially  as  a 
common  denominator  for  the  information  services,  supporting 
tradeoff  decisions  and  preserving  information  savings  for 
the  i nf or ma t ion -e f f ic i en t  manager  to  spend  on  other 
information  services. 

2 .  Auditable  Identification  of  Users 

A  basic  concept  in  any  branch  of  accounting  is  the 


audit  trail,  the  ability  to  reconstruct  for  any  entry  in  the 
record,  the  series  of  transactions  that  originated  or 
altered  it.  Conversely,  for  any  original  entry  or 
transaction  the  audit  trail  tells  you  which  permanent 
records  it  affected.  The  financial  nature  of  management 
control  that  we  have  developed  insists  that  the  user 


authorization  and  identification  structures  used  in  the 


various  subsystems  of  the  IRM  Architecture  be  auditable, 
that  they  maintain  or  can  reconstruct  a  complete  audit  trail 
from  end  user  to  ultimate  database. 

In  addition  to  insuring  auditability  of  IRM 
financial  accounting  and  chargeback,  an  auditable  user 
identification  scheme  reinforces  system  security,  and  by 
increasing  the  perceived  threat  of  apprehension,  strengthens 
the  policy  and  procedure  controls  of  the  system.  Another 
perception  that  benefits  from  secure  identification  is  the 
perceived  equity  of  the  chargeback  system.  Since  not  all 
users  nor  all  applications  can  be  equally  important  to  the 
organization,  the  most  a  chargeback  system  can  hope  for  is 
"perceived  equity".  [Ref.  10:  p.  260]  An  auditable  access 
scheme  documents  for  the  user  that  the  charges  received  did 
originate  in  his/her  department,  and  reinforces  a  perception 
of  equity. 

The  high  degree  of  telecommunications  in  the  IRM 
Architecture,  with  some  systems  open  to  several  networks, 
means  that  simple  password  systems  will  not  provide  adequate 
protection.  This  communications  vulnerability  is  aggravated 
by  the  periodic  transfers  of  the  Coast  Guard's  military 
personnel.  User  accounts  are  often  only  logical  partitions 
in  the  same  computer,  accessed  by  a  network  common  to 
several  physical  user  sites.  Passwords  could  not  protect  a 
filespace  from  an  old  authorized  user  at  a  new  duty  station. 
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Some  hardware  identification  (such  as  a  terminal  identifier) 
at  least  needs  to  be  added  to  all  systems.  To  preserve  the 
audit  trail,  space  for  this  terminal  identifier  and  the  user 
i.d.  needs  to  be  designed  into  network  message  headers.  Once 
the  access  and  message  header  configurations  are  frozen,  the 
incremental  costs  of  adding  security  and  auditability  will 
be  much  higher,  as  will  the  temptation  to  forego  the  expense 
and  rely  on  procedures  alone  for  control. 

3 .  Meaningful  Chargeback  System( s ) 

The  goals  of  a  meaningful  chargeback  system  are  to 
express  the  costs  of  information  in  the  terms  of  the  user's 
units  of  work,  and  to  understandably  identify,  accumulate, 
and  return  to  the  user  all  information  costs  associated  with 
his/her  work  operations.  Ultimately,  such  a  system  would 
completely  satisfy  all  four  of  the  evaluation  criteria 
listed  in  Chapter  III.  The  system  administrative  overhead 
necessary  for  the  financial  reporting  and  user 
identification  requirements  just  discussed  will  also  enable 
a  user-oriented  chargeback  system  to  be  implemented,  as  a 
third  benefit  to  offset  those  same  costs. 

One  possible  implementation  of  such  a  chargeback 
scheme  is  as  an  interface  accounting  program,  which  would 
accept  inputs  from  the  various  subsystems,  sort  them  by  user 
identification,  cross  reference  with  user  budgets  and 
transaction  totals,  and  produce  a  average  cost  per 


transaction  type,  detailed  to  identify  information  subsystem 
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costs.  Such  a  system  would  have  to  be  both  modular  and 
flexible  by  design,  to  allow  subsystems  to  be  added  and 
removed  as  configurations  and  technology  changed.  Locating 
it  as  close  to  the  user  as  possible  in  the  architecture 
would  allow  all  higher  systems  to  run  "off-the-shelf" 
computer  resource  monitors,  modified  only  enough  to  record 
both  user  and  terminal  identifications. 

4 .  An  Information  Marketplace 

Users  could  make  trade-off  decisions  rather  easily 
when  the  services  were  all  available  from  one  source  (the 
EDP  department),  or  even  were  direct  substitutes  for  each 
other  (service  bureau  versus  in-house,  for  the  same 
product).  The  number  of  alternative  information  services, 
and  the  number  of  ways  to  obtain  them  are  both  growing 
rapidly,  even  within  the  unifying  device  of  the  IRM 
Architecture.  Strict  dollar  cost  is  not  an  accurate  basis 
for  comparison  or  competition  any  longer.  The  Support 
Program  Plan  identifies  timeliness,  quality  (accuracy  and 
precision),  quantity,  and  cost  (of  collection,  transmission, 
storage,  and  use  )  as  components  of  information  of  interest 
to  the  Coast  Guard  [Ref.  2:  p.  5-1  ].  Few  among  user 
management  will  have  the  information  judgement  to  evaluate  a 
straight  cost  for  service  against  its  value  along  those  four 
parameters.  Some  set  of  adjusted  prices,  or  factors  by 
which  to  weight  costs  will  be  necessary  to  create  an 
information  marketplace  where  products  and  services  of  the 
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various  information  subsystems  can  be  directly  compared. 
The  user  is  the  expert  on  the  benefits  to  his  program  that 
the  service  will  provide;  the  architecture  will  have  to 
provide  him/her  a  basis  for  properly  comparing  and 
evaluating  the  costs  of  that  service,  if  the  Coast  Guard 
intends  to  hold  the  user  accountable  for  an  effective  and 
efficient  decision.  This  could  be  as  simple  as  a  set  of 
adjusted  prices  for  a  generic  example,  (i.e.  the  average 
letter  costs  2.6  times  as  much  as  a  message)  coupled  with 


substitution  rules  and  judgement  criteria  (letter  vs 
message:  consider  speed  and  security),  or  as  complex  as  a 
database  of  currently-calculated  weighting  factors  available 
to  an  automated  decision-making  tool. 

5.  An  Information  Decision-making  Tool 

In  addition  to  creating  the  information  marketplace 
by  publishing  a  list  of  adjusted  or  general  substitution 
prices,  the  system  should  provide  a  consumer's  guide  to 
proper  shopping.  This  will  insure  the  most  effective 
accomplishment  of  the  IRM  architecture's  management  control 
mission  through  pricing  and  chargeback. 

It  is  to  the  Coast  Guard's  advantage  to  have  users 
making  the  most  effective  and  efficient  information 
decisions  possible.  The  user/manager  is  best  qualified  to 
make  the  cost/benefit  comparison  of  alternative  information 
services.  The  goal  of  the  chargeback  system  is  to  provide 
that  user/manager  the  best  possible  cost  information  to 


combine  with  his  best  possible  benefit  knowledge,  and  then 
hold  him  accountable  for  the  decision.  The  manager  will 
develop  an  information  decision  'support  system'  for  these 
decisions,  if  only  a  set  of  notes  on  how  the  last  one  was 
done.  There  will  be  a  faster  learning  curve  and  more 
consistent  results  if  the  IRM  architecture  recognizes  this 
and  supports  the  manager's  decision  by  some  standard  means. 

A  published  set  of  suggested  procedures  (cookbook 
guide)  could  couple  with  a  price  list  to  produce  trade-off 
decisions  standard  enough  to  be  comparable  and  reproducible. 
Eventually,  a  spreadsheet  program  able  to  access  a 
substitution  price  table,  or  to  calculate  weighted  prices 
from  the  chargeback  information  could  be  developed.  Some 
project  lifecycle  guidelines  could  be  incorporated  in  such  a 
program  painlessly.  In  whatever  manner,  some  decision 
support  should  be  developed.  To  have  management  control 
through  pricing  and  chargeback  work  properly,  we  assume  the 
goods  are  substitutable,  and  the  consumers  have  perfect 
knowledge  of  both  price  and  substitutability.  We  further 
assume  they  will  make  the  logically  best  choice.  These  last 
two  suggestions  for  the  IRM  architecture  (information 
marketplace  and  decision  support)  attempt  to  insure  those 
assumptions  are  met,  and  to  assist  the  user  in  the  choice 
best  for  his  unit  and  for  the  Coast  Guard. 


IMPLEMENTATION  SUGGESTIONS 


1 .  The  Standardized  User  Interface 

In  a  system  as  large  and  as  distributed  as  the  Coast 
Guard  IRM  Architecture,  operating  under  Federal  rules  for 
competitive  procurement,  it  is  almost  certain  that  the 
various  subsystems  (both  hardware  and  software)  will  be 
developed  separately.  Unless  specifically  controlled,  the 
interface  each  subsystem  presents  to  the  user  will  vary  from 
one  subsystem  to  another.  The  interface  includes  such  things 
as  the  location  and  size  of  text,  the  method  of  specifying 
commands  (numbers,  letters,  words),  the  method  of  presenting 
options  (text  or  a  menu)  and  other  guidelines  to  the  user 
for  input. 

At  the  extreme  range  of  variation  of  these  inter¬ 
faces,  an  identical  command  will  have  different  meaning  and 
effect  in  two  different  systems  which  a  single  user 
routinely  accesses.  (For  example,  STOP  in  one  system  halts 
text  scrolling  on  a  display  screen,  in  another  it  ends  the 
session. ) 

Specifying  a  standard  user  interface-  to  be 
maintained  by  all  subsystems  simplifies  learning  and  use  of 
the  entire  coordinated  system  greatly.  It  provides  a 
mechanism  for  the  smooth  introduction  of  change  as  well,  by 
preserving  for  the  user  as  much  of  the  familiar  as  possible 
as  an  environment  for  the  new  function  or  command.  A  major 
advantage  is  that  once  an  effective  user  interface  for  a 
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given  system  or  subsystem  is  developed,  that  design  can  be 
'frozen'  from  change  for  a  while,  preserving  the 
effectiveness  of  the  interface  through  other  system  changes. 
We  have  seen  that  chargeback  and  management  control  systems 
change  to  match  the  maturity  and  growth  of  the  information 
system  overall.  Expecting  that  change,  a  standard  user 
interface  should  be  developed  and  incorporated  in  all 
automated  portions  of  the  control  structure  of  the  IRM 
architecture. 

2 .  Prototype/I terate/ Adapt 

We  have  already  characterized  portions  of  the 
proposed  management  control  structure  for  the  IRM 
architecture  as  a  decision  support  system  for  the  user  in 
purchasing  information  services.  That  tool  could  also 
function  as  a  decision  support  system  for  the  organization 
in  choosing  those  prices  which  will  produce  the  desired  user 
behavior.  A  proposed  new  price  for  a  single  service  could 
be  tested  by  running  the  user's  decision  tool  program  with 
that  price  as  an  input.  The  price  could  be  adjusted  until 


the  desired  decision  was  reached,  or  the  model  could  be  run 
'backward'  to  determine  the  specific  price  change  required. 


Users  do  not  know,  or  cannot  articulate  what  they  want 
and  need.  They  need  an  initial  system  to  react  to  and 
improve  upon. 


★ 

*  The  users'  concept  of  the  task  and  perception  of  the 
nature  of  the  problem  changes  as  the  system  is  used. 

*  Actual  usages  (of  DSS  )  are  almost  always  different 
from  the  original  intended  ones.  In  fact  case  studies 
show  that  many  of  the  most  valued  and  innovative  uses 
could  not  have  been  predicted  when  the  system  was 
originally  designed. 

*  Intended  users  of  the  system  have  sufficient  autonomy 
to  handle  the  task  in  a  variety  of  ways,  or  to  differ 
in  the  way  they  think  to  a  degree  that  prevents 
standardization  of  process. 

Several  studies  [Refs.  12,  13,  14]  suggest  that  the  best 
method  for  designing  a  system  in  such  a  loosely-defined 
situation  is  by  an  iterative  design  process.  The  steps  in 
the  process  include: 

1 .  Identify  an  important  subproblem. 

2.  Develop  a  small,  but  usable  system  to  assist  the  user. 

3.  Refine,  expand  and  modify  the  system  in  cycles. 

4.  Evaluate  the  system  constantly. 

This  design  approach  starts  with  an  prototype  system,  which 
adapts  in  successive  iterations  to  the  user's  and  the 
designer's  experiences.  By  definition  it  is  flexible  and 
adaptable.  This  method  is  proposed  as  a  design  alternative 
to  classic  system  life  cycle  design,  which  attempts  to 
define  all  possible  system  requirements  in  the  initial  study 
phase,  and  then  delivers  a  specific  system  to  satisfy  those 
requirements.  A  major  change  in  such  a  system  requires  a 
return  to  the  study  phase  and  a  new  set  of  requirements.  An 
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advantage  of  iterative  design  is  that  several  different 
small  prototypes  can  be  run  in  parallel,  and  evaluated 
before  selecting  a  standard  model  for  system-wide 
implementation  testing. 

The  various  programs  and  systems  to  satisfy  the 
management  control  requirements  previously  listed,  with  the 
single  exception  of  the  structure  for  aggregation  of 
financial  information,  should  be  developed  using  this 
iterative  design  methodology.  The  complex  and  ill-defined 
nature  of  the  control  problem,  plus  the  need  for  the  control 
system  to  continually  grow,  support  using  a  method  focused 
on  development  of  poorly  defined  and  flexible  systems. 

The  appropriate  place  to  initially  install  the  prototype 
systems  to  begin  satisfying  the  proposed  management  control 
requirements  is  at  the  level  of  the  District  Office,  for  a 
number  of  reasons  which  will  be  fully  developed  in  the  next 
chapter.  An  implementation  incorporating  several  of  the 
necessary  control  elements  into  a  District  Office  Local  Area 
Network  will  also  be  described. 


V.  THE  DISTRICT  OFFICE  LOCAL  AREA  NETWORK 
IMPLEMENTATION  OF  MANAGEMENT  CONTROLS 

A.  WHY  THE  COAST  GUARD  DISTRICT  OFFICE 

The  major  reason  for  placing  the  management  control 
structures  of  the  Coast  Guard  IRM  architecture  at  the  level 
of  the  District  Office  is  to  remain  congruent  with  the  rest 
of  the  organization.  The  District  Office  exercises  manage¬ 
ment  control  over  every  other  operational  program  and  staff 
function.  In  the  financial  chain,  for  example,  the  District 
Comptroller  approves  operating  unit  budgets  with  the 
concurrence  of  the  district  program  manager.  For 
administrative  information  control,  all  official 
correspondence  and  reports  enroute  from  operating  units  to 
Headquarters  must  be  endorsed  by  the  district  program 
manager  in  the  chain  of  command  for  the  originating  unit. 
Management  control  of  the  information  program  logically 
belongs  at  the  District  Office  as  well. 

The  District  Office  is  the  level  at  which  hierarchical 
information  is  aggregated  for  forwarding  to  Headquarters,  as 
illustrated  in  Figure  3.  The  Coast  Guard  District  block  in 
the  IRM  architecture  (as  illustrated  m  Figure  1)  is  also 
the  system  node  with  tr.o  most  connections  to  other  networks 
and  units.  This  center  of  connectivity  is  the  best  place  to 


easily  collect  a  maximum  amount  of  data  about  computer  and 
communication  systems  usage. 


With  the  installation  of  minicomputers  in  each  of  the 
twelve  Coast  Guard  Districts  scheduled  for  FY  86,  the 
processing  power  will  be  available  to  run  the  monitor, 
accounting  and  user  identification  programs  necessary  to  the 
prototypes.  There  will  also  be  sufficient  data  storage 
capacity  available  to  accumulate  an  historic  data  base  on 
usage  and  usage  patterns  for  information  services. 

People  resources  are  at  the  District  Offices  as  well. 
The  District  IRM  officers  are  in  place  with  the  knowledge  to 
run  and  evaluate  the  prototype  control  systems.  The  other 
district  program  managers  make  up  a  team  of  knowledgeable 
control-oriented  managers  ready  to  fully  test  the  various 
prototypes  and  suggest  changes.  Because  of  these  program 
managers,  the  IRM  control  problem  at  the  District  office 
will  be  the  most  difficult,  and  therefore  the  richest  in 
terms  of  potential  learning  about  user  requirements. 

The  district  program  managers  are  management  controllers 
themselves,  of  units  and  programs  for  a  geographic  area.  A 
major  mission  of  the  district  IRM  staffs  will  be  teaching 
them  how  to  use  information  services  in  exercising  that 
management  control.  As  the  need  for  control  of  the  IRM 


architecture  grows,  the  district  IRM  staff's  job  will  become 
controlling  these  other  controllers,  and  through  them  their 
units,-  to  promote  more  efficient  and  effective  use  of 


the  architecture  overall,  and  an  early  start  on  the  problem 
may  ease  a  difficult  transition  from  teacher  to  tax  man  for 
the  district  IRM  staff  later  on. 

B.  WHY  THE  LOCAL  AREA  NETWORK 

Throughout  the  thesis  we  have  been  attempting  to  develop 

the  need  for,  and  requirements  of,  management  control 

structures  for  the  entire  Coast  Guard  IRM  Architecture,  as 

one  large  but  integrated  system.  That  integration  is  an 

express  intention  of  the  Office  of  C3: 

"The  IRM  architecture  and  other  policies  of  the  (Office  of 
C3)  program  discourages  the  proliferation  of  field-unit 
terminals  connected  independently  to  single-program 
central  data  bases.  This  would  be  an  electronic  version 
of  our  present  uncoordinated,  overlapping,  manual 
information  system."  [Ref.  1:  pp.  4-7] 

While  the  management  control  requirements  we  have 
developed  are  applicable  and  useful  to  any  of  the  single 
vertical  information  systems  within  the  overall  architecture 
(e.g.  Personnel  Management  Information  System  (PMIS),  Marine 
Safety  Information  System  (MSIS)),  they  are  also  powerful 
devices  for  logical  integration  of  these  separate  systems 
into  a  single  architecture,  from  the  user's  point  of  view. 
To  accomplish  this  integration,  the  controls  must  be 
applied,  or  at  least  appear  to  the  user  to  be  applied,  as  a 
single  part  of  a  unified  architecture. 

To  those  who  have  read  the  various  planning  and  support 
documents  of  the  IRM  architecture,  it  is  a  logical  whole, 
and  its  integration  of  systems  is  obvious.  However,  if  the 
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user  of  the  system  confronts  a  different  interface  screen 
and  different  sign-on  procedure  for  each  of  the  subsystems 
( PM  IS,  MSIS)  he  or  she  uses,  and  if  each  of  these  subsystems 
returns  a  separate  chargeback  bill  which  the  user  must 
"integrate"  with  a  hand  calculator,  then  the  IRM 
architecture  has  not  achieved  its  'single  system'  goal. 

The  single  physical  device  connecting  all  the 
information  resources  of  the  CG  District  block,  in  the 
Figure  1  illustration  of  the  architecture,  is  the  'local 
net',  the  District  Office  Local  Area  Network  (LAN).  When 
fully  operational,  this  local  net  will  be  the  port  through 
which  all  district  information  services  can  be  accessed. 
Application  of  the  IRM  architecture's  management  controls 
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C.  MEETING  THE  REQUIREMENTS  WITH  THE  LAN 

Each  of  the  management  control  requirements  will  be 


discussed  separately  below  for  a  configuration  that  assumes 
an  operating  local  area  network  is  in  place. 


Financial  Information 


While  no  physical  program  or  device  is  needed  to 
satisfy  this  requirement,  the  necessary  changes  to  the 
financial  accounting  structure  will  need  to  be  defined 
before  the  design  configuration  is  frozen  for  other, 
automated  portions  of  the  control  structure.  The  accounting 
changes  may  add  extra  data  items,  or  expand  the  size  of 
existing  data  items,  throughout  the  architecture,  to  ensure 
that  the  information  necessary  for  the  audit  trail  and  for 
pr o j ec t - le ve 1  aggregation  of  information  costs  is 
maintained.  For  example,  adding  a  field  to  a  message  header 
to  hold  a  project  identification  may  change  hardware  and 
software  throughout  the  system. 

2.  Auditable  User  Access 

The  District  LAN  is  the  IRM  system  entry  port;  user 
and  terminal  identification  should  be  demanded  and  tested 
here.  This  begins  and  maintains  the  audit  trail  at  the  point 
of  first  entry  for  all  users  at  or  below  the  District  Office 
level.  Once  the  user  is  authorized  access  to  the  network, 
the  network  can  then  access  all  subsequent  communications 
links  and  computers,  providing  the  appropriate  access 
information  and  identifying  the  user  and  terminal  to  the 
other  systems. 

This  eliminates  the  problem  to  the  user  presented  by 
a  multitude  of  different  access  procedures  for  each  of  the 
different  intermediate  services.  For  example,  to  access  the 


Operational  Information  System  computer  in  New  York,  the 
user  must  dial  the  local  number  of  GTE  TELENET,  and  comply 
with  their  sign  on  procedures,  providing  an  account  number 
and  a  password,  then  requesting  the  connection.  Once 
connected  to  the  OPINS  computer,  a  minimum  of  three  more 
i.d.  and  password  combinations  are  necessary  to  reach  a 
working  level  successf ully.  The  importance  of  the  informa¬ 
tion  involved  justifies  the  security,  but  the  tedium  to  the 
user  has  prompted  the  OPINS  configuration  managers  to 
authorize  an  programmable  modem  (computer  communications 
device)  to  be  installed  in  their  systems.  This  modem  then 
allows  a  user  to  access  the  remote  computer  with  the  push  of 
a  single  button.  The  protocols,  identification  numbers  and 
passwords  are  all  programmed  into  the  modem,  and 
automatically  presented  to  the  necessary  subsystems.  The 
audit  trail  is  lost--the  system  cannot  record  a  unique 
identification  (number,  password  and  terminal  i.d.)  of 
whichever  user  pushes  the  button.  Satisfying  the 
requirement  for  auditable  user  identification  at  the  initial 
access  to  the  District  LAN  would  preserve  the  utility  of 
automation  such  as  this  while  not  losing  security  or 
auditability.  Overall  system  security  would  actually 
increase  by  recording  the  user  identification  data  provided 
to  the  LAN  by  people  repeatedly  attempting  access  to  systems 
for  which  they  were  not  authorized. 
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This  automation  provides  more  than  user  convenience. 
The  various  information  subsystems  (PMIS,  MSIS)  are  reached 
via  different  communications  networks,  and  once  accessed 
have  different  password  procedures  and  file  structures.  If 
the  user  must  record  and  maintain  the  access  information  for 
each  system  separately,  then  the  fact  of  their  separateness 
as  subsystems  is  reinforced  each  time  any  subsystem  is 
accessed.  If  the  various  subsystems  all  appear  as  selections 
on  an  "Access  Menu"  once  the  user  has  signed  on  to  the  LAN, 
they  are  reinforced  as  parts  of  a  unified  system. 

One  alternative  to  LAN  user  identification  data 
capture  is  distributing  unique  identifiers  and  passwords  for 
all  individual  units  at  the  destination  end,  (i.e.  OPINS) 
and  auditing  use  for  chargeback  there.  Administering  both  a 
billing  and  a  password  maintenance  system  adds 
administrative  overhead  at  the  highest  level  of  the 
architecture.  Collection  of  the  usage  data  is  removed  from 
the  level  of  enforcement  of  the  charges,  and  the  user's 
perception  of  autonomy  and  system  equity  may  suffer. 

3 .  Meaningful  Chargeback  System 

A  meaningful  chargeback  system  provides  information 
useful  to  the  user.  While  the  initial  chargeback  systems 
will  not  be  refined  enough  to  track  each  user  in  detail  and 
express  all  costs  in  terms  of  the  user's  work  units,  the 
'useful  information'  goal  can  be  preserved  during  the 
iterative  development  of  the  chargeback  system,  and  this 


function,  too,  can  reinforce  the  concept  of  unity  for  the 
architecture . 

For  example,  consolidating  and  keeping  track  of  the 
separate  information  service  charges  against  a  user 
division's  total  information  budget  (telephone.  Xerox, 
microcomputer  supplies  and  maintenance,  etc.)  would  be 
useful  to  the  user  while  reinforcing  logical  integration  of 
these  (now)  diverse  services.  A  program  available  through 
the  network  to  extract  such  accounting  data  for  a  given 
user,  producing  an  up-to-the-minute  status  for  his/her 
information  budget  would  do  much  to  associate  resource 
accounting  with  information  rather  than  bills.  Such  a 
program  would  only  require  a  standard  query  to  the 
accounting  database  on  the  District  minicomputer.  Having  the 
program  available  through  the  LAN  allows  IRM  managers  to 
track  how  frequently  the  program  is  used,  as  a  rough  guide 
to  the  'information  awareness'  of  the  entire  staff  or  a 
given  division. 

Often,  before  actual  charges  for  system  use  are 
levied,  the  chargeback  system  is  used  as  a  device  to  notify 
users  of  the  level  and  cost  of  the  information  service  they 
consume.  [Ref.  15:  p.  114],  As  each  of  the  various 
subsystems  gains  resource  accounting  and  reporting 
capabilities,  their  usage  data  could  be  added  to  the 
chargeback  or  'budget  status'  report.  The  transition  to 
actual  charges  would  be  a  gradual  change,  and  the  user  could 
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judge  both  charges  and  usage  data  in  context.  The  single 
budget  report  (bill)  would  reinforce  the  logical  system 
unity,  and  the  LAN  could  make  it  a  recordable  and  easily 
accomplished  event. 

4.  An  Information  Marketplace/Decision  Tool 


The  marketplace  concept  is  an  attempt  to  identify 
the  functions  and  costs  of  the  information  services,  and  to 
identify  the  substitutions  possible  between  them.  It  intends 
to  develop  in  the  user  a  holistic  view  of  information 
processing  and  to  influence  his/her  conduct  with  pricing. 
If  functionally  similar  services  are  available  through  the 
LAN  as  a  series  of  substitution  lists  or  function  menus,  the 
physical  presentation  strongly  reinforces  the  logical 
integration  and  substitutability  the  management  controls  are 
trying  to  develop.  Rather  than  remembering  that  electronic 
mail  and/or  record  communications  messages  can  substitute 
for  hard  copies  on  letterhead  stationery,  the  user  chooses 
one  or  the  other  from  an  "Output  Menu"  and  the  network 
delivers  the  user's  document  to  the  appropriate  device.  Or, 
the  user  could  select  several  options  and  compare  their 
prices  before  committing  the  document  for  delivery.  The 
decision  tool  could  be  incorporated  as  a  "How  Much?"  command 
available  to  compare  possible  choices  in  terms  of 
information  dollar  costs.  Not  all  of  the  options  need  be 
physically  connected  to  the  LAN.  Telephone  calls  are  a  valid 
substitute  for  letters,  but  may  not  be  directly  available 
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through  the  system.  As  long  as  their  prices  appear  in  the 
decision  tool  models,  and  they  are  listed  as  alternates  on 
the  appropriate  function  (Input,  Output,  Send,  Analyze) 
menu,  services  like  the  telephone  and  the  stand  alone 
microcomputer  will  be  included  in  information  marketplace, 
and  therefore  subject  to  the  management  controls  of  the  IRM 
architecture. 

Again,  if  the  information  decision  tool  is  available 
through  the  LAN,  its  use  can  be  recorded  as  measure  of 
information  awareness.  If  the  LAN  can  access  the  separate 
communications  and  information  subsystems  to  connect  users, 
it  can  also  access  those  subsystems  to  get  current  pricing 
and  usage  statistics  for  incorporation  in  the  information 
decision  tool  models. 

The  function  menus  insure  that  the  user  is  reminded 
of  the  possible  substitution  alternatives  at  the  time  the 
choice  is  made.  The  decision  tool  insures  that  the  best 
possible  cost  information  is  available  to  support  the 
choice.  Satisfying  these  requirements  at  the  District  LAN 
interface  insures  the  choice  is  among  all  the  options  and 
all  the  information  services  available  to  the  user's 
purpose,  within  the  whole  architecture,  as  opposed  to  only 
those  choices  available  within  a  given  information 
subsystem. 


Standard  User  Interface 


Although  not  listed  as  a  management  control  require¬ 
ment,  the  idea  of  a  standard  interface  between  the  IRM 
architecture  and  the  user  is  another  physical  way  to 
strengthen  the  user's  perception  of  the  architecture  as  a 
unified  system,  as  opposed  to  a  collection  of  systems.  It 
could  easily  be  implemented  in  the  proposed  LAN  environment 
by  using  a  standardized  interface  in  the  programs  designed 
to  satisfy  the  control  requirements. 

A  hidden  advantage  to  this  approach  is  that  it 
minimizes  expense;  once  the  interface  is  designed,  the  same 
specifications  are  used  for  each  subsequent  program.  Only 
the  information  presented  on  the  screen  changes;  the 
location  of  status  information  and  instructions,  the  type  of 
selection  (e.g.  by  letter,  from  a  menu),  and  all  the  other 
presentation  characteristics  are  identical.  It  also  shortens 
the  user  learning  time.  A  user  recognizes  the  format  and 
can  instantly  transfer  experience  with  the  interface  he  or 
she  gained  using  other  programs. 

D.  A  VIRTUAL  LAN 

A  variety  of  networks  are  available  to  connect  computers 
and  communications  devices,  each  with  a  variety  of 
characteristics,  and  each  calling  itself  a  Local  Area 
Network.  Active  or  passive,  broadband  or  baseband,  central 
or  distributed  control,  the  list  of  options  is  almost 
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endless.  Network  technology  is  not  fully  developed  yet,  as 
the  Support  Plan  recognized  in  deciding  not  to  include  it 
in  the  near-term  budgets.  The  Local  Area  Network  we  have 
examined  to  support  the  integration  and  management  control 
goals  of  the  Coast  Guard  IRM  Architecture  is  not  a  specific 
product.  The  phrase  is  intended  to  describe  an  ability  to 
electronically  cross -connect  the  users,  computers  and 
communications  resources  of  a  Coast  Guard  District  Office  in 
a  productive  way.  This  virtual  LAN  should  provide  reasonably 
guaranteed  delivery  of  information  between  any  pair  of 
nodes,  notification  of  non-delivery,  and  an  auditable  record 
of  access  and  use  of  its  services. 

This  limited  functionality  is  an  adequate  base  from 
which  to  develop  prototype  systems  or  programs  to  satisfy 
the  specified  management  control  requirements,  and  is 
available  at  less  technological  risk  than  that  a  'real'  LAN 
represents.  Shared  logic  word  processors,  such  as  WANG  OIS- 
1  4  0 '  s  provide  electronic  mail  and  hardware  terminal 
identifiers;  they  have  been  connected  to  the  record 
telecommunications  system  in  the  First  and  the  Fifth  Coast 
Guard  Districts.  The  Eighth  and  the  Seventeenth  Coast  Guard 


Districts  are  currently  running  Office  Automation/ Word 
Processing  evaluations  on  Vax  11/780  computer  based  systems; 
these  also  support  electronic  mail,  and  have  resource  usage 
monitor  programs  available.  The  District  minicomputers 
scheduled  for  FY  86  purchase  and  installation  could  provide 


this  virtual  LAN  function  through  their  installed  terminals 
and  the  appropriate  programming.  Any  of  these  systems  with 
a  sufficiently  large  base  of  connected  users  could  provide 
an  adequate  functional  base  on  which  to  prototype  a  system 
or  program  intended  to  meet  one  or  more  of  the  management 
control  requirements  of  the  IRM  architecture. 

E.  SUMMARY 

We  have  presented  the  reasons  that  the  Coast  Guard 
District  Office  is  the  crucial  level'  within  the  IRM 
architecture  at  which  to  address  the  solution  to  management 
control  requirements  of  that  architecture.  The  power  of  a 
Local  Area  Network  to  physically  reinforce  the  logical 
integration  crucial  to  the  IRM  architecture  and  to  the 
success  of  its  management  controls,  was  presented  and 
examined  for  each  of  the  management  control  requirements 
proposed  in  Chapter  IV.  Finally,  a  distinction  was  drawn 
between  any  specific  technology  or  product  and  the  virtual 
LAN  functionality  required  to  begin  satisfying  the 
requirements . 


VI.  CONCLUSION 

This  thesis  has  attempted  to  present  a  positive 
description  of  the  integrative  power  of  management  control, 
in  the  setting  of  a  large  information  system.  We  have 
suggested  that,  properly  developed,  the  management  control 
structure  can  unify  diverse  information  systems  into  a 
single  architecture,  and  yet  preserve  a  powerful,  if  subtle, 
ability  to  influence  user  choices.  If  developed  early,  the 
control  structure  can  ease  the  necessary  transitions  of 
maturing  information  systems. 

The  management  control  requirements  proposed  assume  that 
the  intention  of  the  Office  of  C^  as  program  managers  for 
the  IRM  architecture  is  to  integrate  the  separate  vertical 
information  subsystems  into  a  cohesive  whole.  The  proposed 
LAN  implementation  of  a  system  to  satisfy  the  control 
requirements  centers  on  accomplishing  that  purpose.  Both  the 
requirements  and  the  LAN  implementation  should  be  evaluated 
with  this  underlying  assumption  of  integrating  the 
architecture  in  mind.  Both  would  have  to  be  modified  to 
support  a  different  concept  of  the  architecture. 

This  early  delineation  of  a  management  control  schema 


for  the  IRM  architecture  may  have  some  practical 
significance  for  the  U.  S.  Coast  Guard.  With  major  hardware 
and  software  procurements  for  the  IRM  architecture  still 
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pending,  the  opportunity  exists  now  to  buy  the  features  or 
capabilities  that  will  be  necessary  to  management  control 
later  on.  More  valuable  than  procurement  opportunities  may 
be  the  necessary  lead  time  created  for  careful  prototype 
development  of  the  programs  and  systems  that  the  management 
control  structure  will  require. 

Although  the  Coast  Guard  IRM  architecture  was  used  as  a 
focus  for  development  of  the  suggested  management  control 
structure,  the  requirements  and  im pi ementa ti or  presented 
could  also  be  applied  to  other  information  systems.  The 
organization  served  by  the  information  system  would  need  to 
have  sufficiently  centralized  control  of  information 
services  that  one  single,  or  several  regional  offices,  could 
set  transfer  prices.  The  company  culture  would  have  to 
support  the  notion  of  user  autonomy  within  limits,  and 
decentralized  decision  responsibility.  The  transfer  pricing 
basis  of  the  control  strategy  assumes  as  well  that 
information  services  costs  are  not  allocated  totally  as 
overhead,  but  charged  to  users  to  a  significant  degree. 

Changing  the  information  flows  of  an  entire  agency  must 
change  the  structure,  if  not  the  nature,  of  the  whole 
organization.  Controlling  the  system  which  implements  these 
changing  information  flows  is  a  necessary  step  to  insuring 

i 

that  the  development  process  will  one  of  directed  growth  and 
not  uncontrolled  change.  This  examination  of  management 
control  within  information  systems  is  meant  to  assist  the 
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